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ABSTRACT 


Recent studies have pointed to the increasing burden 
that is software maintenance. The maintenance of tactical 
systems software will demand resources that exceed those 
expended during the development phase as their numbers and 
time-in-service increase. This increased demand for 
resources requires more effective management of the mainte- 
nance phase and development of the software with maintenance 
in pind. 

This thesis presents those items that should be consid- 
ered and utilized during the development phase to reduce 
Maintenance costs over the life-cycle of the systen. Te 
also presents a model that uses the known configuration of 
the prcegram to estimate the maintenance personnel require- 
ments for that system. These requirements will be estimated 
from the beginning of the maintenance phase to its comple- 
tion. The model utilizes the technique of measuring the 
characteristics of the software to obtain the estimation. 
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Ie ENTRODUCTION 


A. CONTEXT OF THE STUDY AND BACKGROUND 


The maintenance of software that has been acquired and 
made cperational by the government is a growing concern. 
The number of tactical computer programs in service and 
those under development will increase the future requirement 
for more effective and detailed planning of all resources in 
the software maintenance area. Not only the number of these 
systems, but also the length of time that these systems 
remain operational will addto the requirement for more 
effective maintenance management. This management will be 
especially demanding with regards to personnel requirements 
Since this will potentially be the most expensive and diffi- 
cult single resource to manage. 

The Marine Corps Tactical Systems Support Activity 
(MCTSSA) has the Marine Corps responsibility for maintenance 
of the software of tactical systems {Ref. 1]. The objective 
ef this research is to present the current ideas in software 
engineering and maintenance. This study was completed with 
MCTSSA*s function in mind, but this should not be construed 
as limiting the tenets outlined in this paper as being 
limited *o MCTSSA. They should be applicable in varying 
degrees to all software projects. 

It is important at this point to realize that good main- 
tainability begins very early in the software development 
process and can only be planned from the beginning of the 
system life-cycle. Attempts to improve maintainability late 
in the project are potentially hazardous to the integrity of 
the software and extremely can be expensive. The inclina- 
tion on the part of the developers to reduce near-term costs 





at the expense of maintainability almost ensures that the 
effort expended later in the life-cycle will far exceed any 
immediate advantage. 

Mest of the literature available on software maintenance 
and its related aspects falls into the area of general 
purpose computing. Little of the current information avai- 
lable specifically addresses tactical computer software. 
While this initially appeared to restrict sources of infor- 
mation, it became apparent that, even though there are some 
definite differences between tactical and general purpose 
computing, they are less important than the similarities. 
The particularly demanding parts of tactical systems are the 
real-time requirements oor scheduling constraints, and the 
"Geitagal” or “life-and-death™ nature of their decisions. 
In the bulk of general purpose software these features are 
either not present or not present to the same degree. 
(Sef. 2}. The software will to a great extent be similar in 
composition even if the requirements differ. Additionally, 
many of the processors that the tactical systems are based 
on were originally designed for a commercial or general 
purpose systems. 

Software maintenance, for the purposes of this paper, 
will kre defined as those actions which are taken to repair 
or beneficially alter the software in a system that leaves 
the majority of the instructions in the program unaltered 
and the designed function of the system intact. Software 
Maintenance has been divided into two types, corrective 
maintenance and adaptive maintenance [Ref. 3]. 

' Corrective maintenance is that maintenance which is 
required to repair errors or improve the functioning of the 
software without altering its primary functions. The latter 
part of this type of maintenance would concern itself with 
essentially perfecting the programs or making them more 





machine efficient. The repair portion would consist of 
fixing errors. These errors can range in degree from an 
error that results in total failure of the system to an 
error that is bothersome but has no effect on performance 


(Ref. 4]. The second type of maintenance is that of 
enhancement or adaptive maintenance. This occurs when a 
minor change in the function of software is desired. This 


change can improve the system by increasing its capabilities 
or changing its operation to the form that the user desires 
at some time after the system has been made operational. 
The changes made should leave most of the system's software 
as it was. 

Software maintainability is that degree to which the 
software can be changed or corrected. It is the degree of 
ease the maintainer has in understanding the software and 
then applying the proper corrective action or integrating 
the desired enhancement. Software reliability is the extent 
to which the program performs its designed functions accu- 
rately and in a timely manner. These two concepts will be 
related to each other throughout the life of the software. 


B. FORMAT OF THE THESIS 


This paper has been broken into two main sections. The 
first section will describe those methods that should be 
used early in the life-cycle of the software. The objective 
of this section is to present those ideas that should have 
their greatest effect on reducing the total life-cycle cost 
of the software with emphasis on reducing the costs of the 
maintenance phase. It is important to stress that extra 
time cr money spent early in the project can reduce costs 
later in the life-cycle of the software at an extremely 


favorable rate. 
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The second section of the paper will deal with 
presenting a proposed model for the predicition of the 
personnel required for maintenance of a system's software 
once MCTSSA assumes full responsibility for this function. 
An important feature to note inthis model is that it is 
based on the known and quantifiable parts of the software. 
The programs have already been written and thus MCTSSA will 
know what they consist of. This fact alone should aid the 
predictive capabilities of the model. 
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II. DESIGNING SOFTWARE FOR MAINTAINABILITY 


SE Se ee —= ———— = =e ae 





B- SOPTWARE LIFE-CYCLE 


The software life-cycle can be divided into six distinct 
areas. These are Requirements Analysis, SPeECit leatzon, 
Design, Coding, Testing, and Operations and Maintenance (see 
Pagure 2.1) {Reft. 5]. Each of these areas can be further 
broken into sub-areas and often overlap. Only those items 
that are pertinent to maintenance will be developed. 


Be. REQUIREMENTS ANALYSIS 


During the requirements analysis the type of system and 
its capabilities are identified. This process takes place 
between the user and the developer. Although in the past 
this phase has been considered less important, it is both 
critical to successful maintenance and difficult. De teal 
critical because one must ensure that the user's require- 
ments are met and it is difficult because this phase has not 
lent itself to the Kind of structuring that allows a cook- 
book or step-by-step approach. The user and developer 
during this phase attempt to determine «he user's needs, a 
step which is often difficult to accomplish with the tech- 
nical tools available to conduct the project [Ref. 6]. 

Items that are important to consider during this phase 
which improve subsequent maintainability include, first, 
identifying the maintenance group (in this case MCTSSA) and 
including them in the review of the system requirements 
(met. 7}. The purpese of this is twofold, first, to deter- 
Mine the maintenance facility's capability to support 
maintenance and to allow the maintenance managers to begin 
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FIGURE 2.1 Software Life Cycle Phases. 


McClure, Carme |, managing Sattsece Develapsent and Malntensoca, 
van Nostrand Relnhold Company, Figure 3.1, D. 33. 





planning for the maintenance phase 9f the project in rela- 
tion to the other systems currently sperational. Second, it 
is at this time that thought should be given to developing 
schedules of priorities, enhancements, and resource alloca- 
tion. The enhancement portion would be extremely difficult 
to define precisely, but planning for it needs to be 
conducted in some form as experience has shown that this 
a@ceounts for, on the average, forty-two percent of the 
Maintenance effort [Ref. 8]. This early identification of 
enhancements should afford the maintenance facility enough 
lead time to begin considering its support requirements. 
The previous experience of the facility in dealing with 
enhancements should also allow it to make an estimate of the 
enhancement rate. The development of enhancement estimation 
should include data gathered from both the vendor and the 
facility. This requires the establishment of a database 
that deals with «hese areas and is readily available to the 


Managers of the software maintenance facility. 


C. SPECIFICATION PHASE 


It is during the specification phase that the functions 
of the system are defined. This has to be done with the 
user to ensure that his requirements will be met. Pailure 
to accomplish this will result in costly corrections either 
before acceptance when discrepancies arise during testing or 
later when adaptive maintenance has to be done to bring the 
System in line with the user's needs. Pigqgumer 2.2, the 
information for which was obtained from the Software 
Maintenance Guidebook by Re LL. Glass and R. A. Noiseux, 
shows how the cost per error increases as the life cycle 
progresses. 

This phase should be conducted between the user and the 
developer to ensure that both understand the potentials of 
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the system. The user so that unreasonable demands or expec- 
tations are not made and the developer to ensure he under- 
stands what the user requires and explain what is within the 
Capabilities of the current technology. 

The specifications give a concise description of the 
system's functions to both the user and the developer 
fRef. 9]. The completeness and correctness of these speci- 
fications will govern the entire project. Good specifica- 
tions will afford management better estimates of the 
magnitude of the project for scheduling purposes. 
Conversely, poor specifications will result in software that 
Cannot be expected to perform adequately or even be useful 
for the increased costs that it will create. It is during 
this phase that structured programming should be incorpo- 
rated into the project to specify the structure of the soft- 
ware for the design phase. 

During this phase the maintainer should be included in 
review of the specifications and he should evaluate the 
impact on current systems [ Ref. 10}. The latter allows the 
Maintenance facililty to refine the planning for maintenance 
begun during the requirements analysis phase and the former 
allows the maintainer to provide insight as to what sections 
of the program can be provided through reused code. It is 
at this time the identification of those areas that could be 
implemented through the utilization of reused code should 
begin. 


De. DESIGN PHASE 


The design phase is when the structure of the software 
is actually delineated. The designer develops in detail a 
structured hierarchy of modules. This phase is critical as 
studies have identified that almost sixty-four percent of 
the software's errors have arisen from poor design 
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(Ref. 11). A well-structured design will either eliminate 
errors or facilitate detection of design errors early in the 
life-cycle of the system when they are least expensive to 
£#x. This is also the phase during which the most widely 
accepted methods of ensuring maintainability are instituted. 

Structured design is the first of these methods. 

tructured design consists cf following an established set 
of procedures for accomplishing the design phase. It estab- 
lishes the framework for the software and, when properly 
completed, facilitates maintenance The structure or frame- 
work of the modules should be hierarchial with control 
flowing from top to bottom in a logical manner with no level 
calling on a higher level. The top level should be the 
highest level of control logic present {Ref. 12]. 

Part of this structure is the design modules, which are 
those modules that are constructed during the design phase. 
They have been determined to improve maintainability by 
almost e€ighty-nine percent of their users [Ref. 13]. The 
key aspect of the modules 1s that they should perform a 
Single function. This reduces their complexity and allows 
for both easier error checking and error correction. The 
aspect of a single function is important to maintenance as 
it makes the module easier for the maintainer to understand 
what the module is doing. The capacity of the system to use 
previously coded modules is increased through this method. 
Additionally, the flexiblity of the system is increased 
through the plug-in capabilities inherent in modular design. 

During this phase it is again important for the devel- 
Oper and the prospective maintainer +o maintain close 
contact. The maintainer is able to provide insight as to 
what and how the current systems are performing and espe- 
cially to provide information on what functional modules 
have already been coded and are available from previous 
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projects. The object here is to reduce the total effort and 
possibly eliminate any pitfalls that have been experienced 
in previous designs. 

Documentation of the program increases in importance as 
the development of the system progresses. The developer 
should ensure that all steps of the process are explained 
fully. All parts of the hierarchy and modules should be 
explained completely to ensure adequate understanding of 
beth their functions and methods of implementation. This 
will considerably ease the maintainer's burden when he has 
to correct errors cr enhance the system much later in the 
life of the system when these who developed the system are 
not available for explanations as to why and how. The 
Maintenance personnel can provide valuable input to the 
documentation design by providing information on those types 
that have proved especially helpful and easy to use. 


E. CODING 


This phase is possibly the best understood phase in the 
entire life-cycle. However, there are items that need to be 
particularly adhered to if maintainability is to be 
obtained. The first of these is widely recognized as aiding 
both development and maintenance. It is the use of a high 
order language. The greatest contribution of a high order 
language is that it adds readibility to the program, thus 
increasing the understanding cf the code. Another technique 
that will facilitate understanding of the code is the use of 
structured programming. This is the grouping of similiar 
modules and the use of such technigues as indentation of 
inside a program to increase readability. 

Reused code has excellent potential to reduce the life 
cycle ccsts of software. It can do this through reducing 
ecding and tésting of nodules, and consolidation of 
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Maintenance through reduction of the total number of unique 
modules that need to be maintained. It has been applied in 
limited Situations we-h <sijgnaficant improvements an 
productivity and reductions in development and maintenance 
costs (Ref. 14]. The maintenance facility would be required 
to maintain a library of current modules that are available 
for use and in operation. It would also maintain the data 
on those modules in terms of error rates, system locations 
and other important information. 

It 1s during this phase that reused code is inserted 
into the program where it was identified as being suitable. 
Through the reuse of code, not only the coding time but also 
the testing effort is reduced. The reused code has been 
tested and implemented in other systems and has been proven. 
There should be many areas in each new program that provide 
the opportunity for the reuse of code. A reduction in 
required maintenance should occur as one module is repaired, 
the change can be applied to all systems using that module 
(Ref. 15]. The primary advantage in terms of maintenance is 
the reduction in the probabilty of errors being generated by 
that module. 

Upon completion of the coding and the checking of the 
module Ey the programmer, that module should be passed on to 
be checked by another individual. This checker should use a 
checklist that identifies the common errors that arise in 
programs [Ref. 16]. The use of the checklist will improve 
the productivity of the inspection process greatly. An 
example of an inspection checklist can be found in T. Gilb's 

A technique that shows much promise in increasing both 
the maintainability and reliability of software is the use 
of dual code. The dual code technique would be implemented 
during this phase of the life-cycle and consists of 
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utilizing the structure developed during the design phase to 
independently construct two sets of code. While it would 
appear to increase costs by a factor of two, it has in its 
limited application increased costs over the life-cycle from 
five to ten percent in cases where no future benefits have 
been obtained. In most cases, however, a net cost savings 
of up to fifteen percent or a substantial increase in the 
quality cf the code produced has been realized [{Ref. 17]. 
The advantages of dual code can be manifold. The first, 
and most important in terms of tactical systems, is the 
increased quality of the software produced. The reason for 
this is that the two sets of code will check each other. 
The results they produce can be checked to determine if 
there are differences between them and thus possible errors. 
Therefore a check on the quality of the coding is provided. 
This technique would have one program essentially do the 
work of the desk tester, thus automating this step in the 
process [{Ref. 18]. This automation of the desk testing 
process should increase the dependability of the checking 
that is conducted. Dual code is also used in conjunction 
with the bebugging technique, which will be explained later. 


F. TESTING PHASE 


The testing phase can be broken into three parts: unit 
level, integration, and system testing. Unit level testing 
is done for each module to determine if it functions prop- 
erly. Integration testing is completed next and is done in 
either a top-down or bottom-up fashion. It ensures that the 
modules will work properly in the program environment. The 
system test is completed next and is done to ensure that the 
system meets the specification it was designed for. 

The maintainer should be involved in this entire phase 


to give advice on the test methodology. He has curren* 
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information that concerns systems that are on-line and is 
able *o highlight likely areas for extra attention during 
testing. 

Most important during the testing phase is the documen- 
tation of the testing. This documentation should provide 
information on the error rate of each nodule, the type of 
error, and difficulties with the overall systen. Also 
included should be data on the manpower and resources 
required on the project to date, broken down by modules if 
possitle. Table I contains an example of the data that 
should tke included on the program's test history. This 
information is important +o the maintainer as it will give 
hia some idea as to possible trouble spots in the software 
and an overall idea as to the difficulty he will experience 
in maintaining the entire progran. A system that is diffi- 
cult to maintain early in its life time will continue to be 
difficult throughout its entire life and needs to be identi- 
fied as such as early as possible. 


G. MOVEBENT INTO THE MAINTENANCE PHASE 


During a study conducted by Lientz and Swanson, it was 
determined that the best organization for conducting mainte- 
nance is one that performs that function solely. This 
facility should be separate from that of development. They 
gave as possible reasons, increased efficiency and greater 
control cf efforts and reduced costs that arise from this 
specialization [{Ref. 19}. Additional benefits can occur 
through the possible career enhancement of programmers who 
become involved with maintenance. 

A tradeoff of a separate maintenance function as 
compared to one integrated with development is that the 
productivity of the maintainers declines when fewer of the 
original developers are involved in maintenance [Ref. 20]. 
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This can be partially compensated through the use of a 
“maintenance escort" [{Ref. 21]. This escort will take part 
in the development of the software and, when the system's 
responsiblity for maintenance is transferred, he goes along 
with it to provide the needed experience to reduce the 
initial maintenance effort and improve the learning of the 
maintainers. 

Since programmers will not be constantly in demand ona 
specific project, the organization should be constructed 
such that departments with experienced personnel are organ- 
ized around a specific functional area of software, such as 
input, arithmetic, output, Signal processing or data display 
types of software. This would allow the programmers’ to 
become experts on specific areas. The departments would 
consist of functional areas that are common to all projects 
and allow programmers to become experienced with that type 
of function. The departments would send the required people 
to the requesting projects on an as-requested basis. To 
ensure familiarity with the project, specific programmers 
would be allocated to certain projects on a consistent 
basis. The objective of this system is to obtain greater 
utilizaton of experienced programmers, the alternative being 
their complete devotion to a specific project with the 
resulting under utilization of their skills and abilities. 

The management of software maintenance is unique in many 
respects and requires attention to some special areas. 
First, it should be realized that about twenty percent of 
the time the maintainer will actually be employed in correc- 
tive maintenance [{Ref. 22]. The remainder will be employed 
in conducting adaptive maintenance. This is important, in 
that, while it may be difficult to fix bugs in programs, it 
is more difficult and costly to add enhancements to the 
software such that it meets the same stringent requirements 
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of the original product. The maintenance of software is a 
repeating cycle that requires the same steps, although ona 
smaller scale, that were conducted during the development 
phase. Figure 2.3 shows the recommended cycle for including 
enhancenents. 

It 1S important that the addition of an enhancement take 
place in much the same manner as the development process to 
ensure that the quality of the software is maintained. The 
Maintainer needs to document changes, employ structured 
programming and modularization in much the same way. 
Pailure to do so will throughly destroy a good program and 
even shorten its possible useful life. Grit. Galjesto 
conducting adaptive maintenance is the determination of 
whether i* is worth the effort to add the enhancement. An 
evaluation should be conducted on each proposed enhancement, 
to determine if the potential benefits exceed the possible 
long term costs. This process when used on small scale 
enhancements may prove infeasible, but it should definitely 
be required for all enhancements that have the potential for 
consuming large amounts of resources. 

Reused code will show an additional benefit in the area 
of changes. That is, if a change is required in one module 
that change can possibly be instituted in all other 
instances of that module. The correction of an error would 
then only have to be detected and corrected once, rather 
than waiting for the remainder of similar modules *o err and 
require correction. 

Essential to the maintenance function is the accunula- 
tion of data on the various types of projects that are being 
Maintained by the activity. These data need to be tabulated 
from the beginning of the project to its end and require 
completeness. That is the data need to include information 


on the functions and modules of the progran. For instance, 
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they should include the error rate, what types of errors, 
when they were found, and especially how long it took to 
find and repair then. These data will enable management to 
gain better insight into the maintenance process and allow 
them to form better estimates on personnel requirements to 
copdwct this function. Medels can prove useful in this 
respect, but will prove even more useful when there are data 
available to determine their validity. The data accumulated 
will previde much irformatiocn on the maintenance process and 
its usefulness will cross over into other projects because 


of a large degree of common properties in software. 


He. SUMMARY 


One of the ideas that should have beccme apparent fron 
the preceding discussion is that maintenance, quality and 
reliability are intrinsically related. Designing for reli- 
ability and quality, while not necessarily increasing main- 
tainability, will reduce the maintenance costs, if for no 
other reason than the elimination of errors. These three 
are more deeply related because the use of structured 
programming and modularity not only increases maintain- 
ability Ey decreasing complexity but also increases quality 
and reliablity for the same reason. The human programmer is 
able to comprehend only a limited amount of a progran. 
These techniques allow him to understand what he is working 
on and in what context, reducing the probabilty of errors 
early in the life of the system. That is the key to all of 
maintenance, making the software as 2asily understandable as 
is possible, thus increasing the capability of the main- 
tainer to find and repair or add the desired changes. It is 
possible to develop reliable software that is relatively 
complex without making it maintainable; it has prebably been 


done more than once. It 1s easier to accomplish and 
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certainly less expensive to conduct the software development 
process with the objectives of reliablity, quality, and 
Maintainability when these tenets are adhered to than it 
would be if they are not considered. 

The three potential methods to achieve the above objec- 
tives are dual code,reused code and bebugging. The latter 
will be explicitly treated in the following chapter. Dual 
code can increase reliability of code by providing a ready 
check cn that code to ensure that it is error reduced. 
Reused code should reduce costs through reduction in testing 
of modules and coding required. It should additionally 
improve reliability through the use of previously tested and 
proven code. Bebugging will allow the manager to estimate 
the errer rate of the cod2 and its maintainability “hrough 
some simple testing procedures. This method is important in 
that it provides a measure of the quality and maintain- 
ability of the program, thereby improving the planning for 


maintenance. 
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III. SUGGESTED MODEL FOR ZSTIMATING PERSONNEL REQUIREMENTS 
DURING MAINTENANCE 


A. INTRODUCTION 


Pricr to entering the maintenance phase, it is extremely 
iaportant to have an estimate of the resources required to 
conduct it. An especially important part of these resources 
is the personnel requirements. The people who maintain the 
systems software will prove to be the largest single expense 
of the gaintenance portion of the life-cycle. There have 
been a number of models developed t9 estinate the develop- 
ment costs of software and a few have attempted to extend 
their predictions to include the maintenance phase 
{Bef. 23), [Ref. 24], (Ref. 25], [Ref. 26]. The emphasis of 
these gpodels is to utilize the functions, siz2, and applica- 
tions of the software to estigate its life-cycle costs prior 
to the initiation of development and coding. This is essen- 
tially «he a@acro approach to looking at the overall func- 
tions € the system and using them to estimate resource 
requiregents. 

While in many cases any model or estimating technique is 
better than no formalized technique a+ all, «he construction 
of a model should be based on a thorough understanding of 
the components of the systen. This could be considered the 
micro approach. The model presented here is one approach to 
understandirg that portion of the life-cycle called mainte- 
nance. It atteapts to @xplain the interactions of the 
components of software maintenance with a view toward pred- 
icting the resource requirements. Pundamental to the model 
is the fact that the development phase has been completed 


ama that the systee is in use. 
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Therefore, the size, functions, and applications of the 
program are well knecwn and can be utilized in the estimation 
model. This approach should integrate well with MCTSSA's 
role aS a maintenance facility as this is the point in time 
that they assume responsibility for the software systen. 

The presentation of the model covers the two types of 
Maintenance that were defined in Chapter I, corrective 
maintenance and adaptive maintenance. The objective of the 
model is to determine the amount of effort required to 
conduct both types cf maintenance. 

The major assumptions made in this model are that the 
development of the system has been completed and it is 
currently in use. The maintenance facility is assuming 
responsibility for the software and, thus, knows its 
content. This allows for more accurate use of an estimation 
model based on an in-depth analysis of the code itself. 
Further assumptions are that the system has been developed 
in accordance with the guidelines presented earlier in this 
paper. While all guidelines may not have been followed in 
every instance, the model is presented such that the reader 
should be able to adjust its construction to suit his use. 


Be. DEVELOPMENT OF METRIC TO ESTIMATE CORRECTIVE MAINTENANCE 
WOR KLOAD 


1. Bebugging 


"Bebugging" is a term coined by T. Gilb and is 
derived from a concept developed by H. Mills that introduces 
a number of known errors into a program to calibrate the 
error location process [Ref. 27]. The concept is that of 
introducing a known number of errors and then performing a 
debug exercise on the program. The objective is to compare 
the seeded number of errors detected to the errors that 
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cccurred naturally in the program and then use these figures 
to estimate the total number of bugs present in the progran. 
Conducting this test over a specific period of time will 
afford a measure of the bug detection rate. 

G Se@nick atid R. Wolwérton in their article, “An 
Analysis of Competing Software Reliability Models" summar- 
ized the work of H. Mills and the later work of S. Basin and 
presented a formula that can be utilized in calculating an 
estimate of the maximum number of errors present in the 
software. That formula is: 


RE) xXx BH — w(t) + 1 
ep pel AT pet <1> 
= - K (2) 


where, 

N= maximum number of errors, 

INT= integer value of evaluated expression, 

r= number of statements in the test, 

k(1)= number of statements in test in which indigenous 
errors were detected, 

k(2)= number of statements in test in which seeded 
errors were detected, 

n(1)= number of statements in which errors were intro- 
duced, 

M= total number of machine executable statements in the 
system {Ref. 28]. 


This formula is based ona count of the statements with 
errors. The errors are seeded randomly in the entire 


program and in executable instructions only. 
2. Implementation of Bebugging 


The implementation of bebugging should be relatively 


Simple and straightfoward. The seeding of the program needs 
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to be dene randomly. This can be done manually or automati- 
cally through the machine's use of a predetermined algor- 
ithm. The error type to be introduced should be considered 
at this point. The type of error introduced needs to repre- 
sent the proper proportion cf that e2rror in relation to the 
total number of errors. (Ref. 29]. The type of bugs or 
errors considered in this test are semantic. The categories 
of semantic bugs are computational, logical, and data 
(Ref. 30]. The syntactic type of bug is not considered as 
it should be detected during complilation [Ref. 31] and 
design errors are generally considered too difficult to 
artificially introduce. The best method for obtaining the 
proportion of error types is to refer to the vendor supplied 
information on this project and to data that has been accu- 
mulated on other similar projects. The errors introduced 
should reflect this proportion in order to obtain a repre- 
sentative estimate. When the test is run each type of error 
should be calculated separately using the above fornula. 
This is essential as each type of error will require a 
different degree of effort to repair. 

Two methods are readily apparent for detecting 
errors after the program has been seeded. Tie. first of 
these methods is manual detection by the programmer or 
programmers who will be involved in the maintenance of the 
system. It is important that those involved with the 
maintenance participate in the test to achieve calibration 
of the model to the programmer's capabilities and possibly 
eliminate any variance that could arise from differences in 
programmer skill. This will provide additional information 
on how long it takes for the programmer to detect and then 
correct the errors. The test should consist of timing how 
long it takes for the programmer to locate an error by type. 


This could be accomplished by maintaining a time-sequenced 
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listing of when each error was found by type. The detection 
rate could then be established for each error type by 
obtaining the average number of errors detected per a 
specific time, in this case a man-hour. This rate is valid 
if the system is to be constantly reviewed for errors by 
these individuals. The alternative to this method is to 
develop a model which is able to predict an error rate valid 
for +he operating cycle. This model would obtain a value 
that would show the rate at which errors appeared during 
Operation of the system and required repair. 

The second method of obtaining the error count is 
through the use of the dual code technique. Dual code 
provides two parallel implementations of the design specifi- 
cations, in either the same or different languages and has 
been discussed earlier in section E of Chapter II. In the 
bebugging context the seeded or artificial errors are intro- 
duced into one of the code sets. The two code sets are run 
in parallel and their results are compar2d during running 
for discrepancies [Ref. 32]. The differences in the results 
will yield, since the two sets of code were coded indepen- 
dently, indicators as to where errors lie in the progran. 
One set of code will, in effect, check the other through 
this process. The code set with the introduced errors will 
be used to obtain the error estimate. This method will 
yield only an estimation of the total number of errors and 
an error rate per lines of code. It will not allow one to 
determine the maintainabilty cf the code through the use of 
programmers. 

Since the dual code method will yield only an esti- 
mated number of errors, the two methods of manual and dual 
code should be used together. The reason is to obtain a 
check on the number of projected errors, and because only 
the manual method can provide an indicator as to the tine 


32 








Bequiarec to detect and correct errors by a specific 
programmer. If only one method can be used due to resource 
constraints, the manual mathcd is preferred as it provides 
three types of information, that of error rate, detect- 
ability cf the errors, and the maintainability of the code. 

Bebugging was selected as a possible method for the 
maintenance facility to avaluate the software for planning 
purposes for a number of reasons. * is conducted indepen- 
dently of the vendor and allows verification of his data and 
the techniques employed. While discrepancies between esti- 
Mates are sure to arise, large discrepancies should be 
Suspect and should subject either the facility's or vendor's 
methods to re-evaluation. The bebugging test is conducted 
under the conditions and with the people that will be preva- 
lent during the maintenance phase. The test should be rela- 
tively simple to structure and implement by the facility. 
Additionally, the concepts involved are easy to understand 
by those participating. 

There are some distinct disadvantages to bebugging 
that should be discussed. THe first. is thatiat fails to 
identify the degree of error. The degree of an error can 
fall into one of five categories: 1) error which prevents 
the accomplishment of an essential function, 2) error which 
adversely affects the accomplishment of an essential func- 
tion degrading performance, 3) error which adversely affects 
the accomplishment cf an essential function degrading 
performance, but has a work-around solution, 4%) error which 
is merely an operator inconvenience, and 5) all other errors 
(Ref. 33}. As can be seen from the above definitions, the 
degree of the error is the extent to which the system's 
functioning is affected and not the cause of the error or 
error type. The degree of error and design errors do not 
lend themselves to detection though the bebugging technique 
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due to ‘their complexity. Alternative methods need to be 
developed in this area. 

An additional trouble area became apparent during 
research and that is the problems that occur when repairing 
a bug. The possibility always exists for the repairer of 
the bug to introduce additional errors through unpredictable 
effects on other modules. The best insurance to insulate 
against these effects is the preservation of modularity and 
the use of information-hiding modules which do not allow the 
programmer to make any assumptions that could later prove 
dangerous to the program. Additionally, the use of struc- 
tured programming andthe techniques described in Chapter 
II, section C should work to reduce the design errors that 
may develop later. This is exemplified by Figure 3.1. 

The use of bebugging will produce an estimate of the 
error detection rate that can be used for planning purposes, 
if it is recognized that this is just an estimate and not 
what will occur. The bebugging method can be used 
periodically to evaluate the current status of the software 
at various points along the maintenance path. The estimates 
derived therefrom can be used to refine or revise planning 
figures. Purther, greater confidence in an estimate can be 


achieved through more testing, although at additional cost. 


3. Estimation of Corrective Maintenance Workload 











The corrective maintenance workload can be predicted 
using the number of estimated errors in the system and the 
rate of error detection established by the programmers 
during the bebugging test using equation <1>. The error 
detection rate as well as the number of errors’ should be 
divided into the three types of semantic bugs identified 
earlier. The resultant formula should estimate the amount 
of corrective maintenance that will be required on the 


system. 
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The formula is: 


N (c) N(1) N (d) 
CM = ———---— + ~--=-- + -<2---- <2> 
d (c) d(1) d (d) 


where, 
CM= total corrective maintenance required in man-hours, 
N (2) = number OF aL type error estimated 
(c=computational, l=logical, d=data)using equation <1>, and 
d(i) = the detection rate in errors per man-hour of i 
type error. 


C. DEVELOPMENT OF METRIC TO ESTIMATE ADAPTIVE MAINTENANCE 
LOAD 


Adaptive maintance, aS previously defined, is that 
maintenance conducted to improve the system by increasing 
its capabilites or change its operation to a form that the 
user desires after the system is operational. These changes 
or enchancements are accomplished to improve the overall 
efficiency of the systen, add new features, or provide 
interfaces with other systems that were not called for in 
the original design. The enhancements, in many cases, 
should not substantially alter the original design of the 
program. If a major redesign is warranted, the system 
should be returned to the development phase to ensure that 
the design is done properly. The adaptive maintenance 
discussed here will cover those cases where modules may be 
changed or added, but the structure of the original progran 
essentially remains intact. 

The addition of enhancements should be conducted along 
the lines of the original development process to ensure 
that, while the system is enhanced, the changes are inte- 
grated into the system with a ninimal degrading effect on 
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per formance. An understanding of the system to be enhanced 
is required. This understanding is governed by the logical 
and structural complexities of the software. Adaptive 
Maintenance involves two major types of enhancements. A 
porticn of them involves alteration and a small addition of 
code and a portion requires the addition of a new module, 
replacement of an older nodule or a restructuring of the 
software's structure. The degree to which each portion 
presents itself during the life of a system is as yet indet- 
erminate and will require in-depth study. Experience can 
provide some indication as to how often and to what extent 


these two degrees of enhancement are made. 


. Use of Halstead's Effort Metric a 
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In order that a modification may be made, the indi- 
vidual making the change needs to understand the system. The 
amount of time he takes before he can begin useful work on 
the system is governed by the complexity of that system. The 
degree of software complexity is inversely related to the 
level of understanding. The more complex the software, the 
less well understcod it will be until more effort is 
expended in an effort to imprcve comprehesion. 

Halstead's development of programming effort essen- 
tially realized this. Halstead's effort metric was devel- 
oped to analyze the effort required to construct a program 
in a specific language from a preconceived algorithm. Its 
application in maintenance for using it to rate the 
complexity of the software should prove valid. To develop 
programming effort Halstead used the concepts of program 
level and volume [Ref. 34}. 

Program level refers to the level of a program's 


implementation. There is a minimum level of implementation 
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where the fewest number of operands and operators possible 
can be used and the program will still function as intended. 
This most elegant of implementations is never realized in 
fact and some lower program level is achieved. The easiest 
language to use would have a program level of one, where any 
procedure desired would consist of merely acall on that 
procedure. This would require an infinite list of procedures 
and is not realizable. Implementations of programs will 
fall into an area of program level less than one. Use of 
this greater number of statements and the consequent expla- 
hation results in greater understanding of the implementa- 
tion for the person less familiar with the system The 
difficulty of the comprehension of a program varies 
inversely with the level of that program {Ref. 35]. 

AS presented by Halstead, the program level is 
affected by the operators present. The larger «he number of 
operators employed, the lower the level of implementation. 
The minimum number of operators possible is two, where one 
would consist of a function designator and the other an 
assignment operator. The program level is therefore propor- 
tional to the minimum number of operators possible divided 
by the actual number of unique operators [{Ref. 36]. 

Qperands do not show a Similar Minimum over all 
implementions. In cases where an operand name is repre- 
sented, the implementation is ata lower level than was 
possible if the operand was used only once. The progran 
level is then proportional to the ratio of the number of 
unigue operands to the total operand usage [Ref. 37}. 
Combining the two proportionalities and noting that the 
constant of proportionality is one, as this is the maximun 
defined value of program level, yields the program level, L, 


as 
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L = 2 x aah <3> 


HUT V2 
where, 
n(1) = the number of unique operators, 
n(2) = the number of unique operands, 
N(2) = the total number of operands present and two is 
considered the Minimum number of operators possible 
[fRef. 38]. 


Program level represents a meaure of how well the software 
has been implemented in relation to the capabilities of the 
language that has been used. The better the implementation 
the closer to one the value of L becomes. 

Progran volume recognizes the importance of 
obtaining a metric for the size of a algorithm that not only 
measures its physical length but also the number of distinct 
operations performed in the progran. The objective is to 
allow application to a wide variety of languages. Volume V 


has been defined as: 
V= Nin <4> 
Beats 


where, 

Nis equal to length or N1+¢N2, the total number of 
Operators and operands utilized, and 

nis the vocabulary of unique operators and operands or 
n(1)+n(2) [Bef. 39]. 


This volume can be applied to any programming language and 
measures the size of the program in the language coded. [It 
takes into account the capabilites of the language as 
presented by the number of unique operators and operands and 
its size as represented by the total number of operators and 
operands. Program volume represents an overall measure of 
the size of a program in relation to that program's compre- 
hensibility. 
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fo obt@ia the effort saetric, E, Halstead uses the 
ratio of program volume to program level {Ref. 40}. 


E= V/L <>> 


From this equation it can be seen that as the program volune 
increases, the effort or complexity will increase and that 
as the program level increases the effort decreases in kind. 
Executing the necessary substitutions to allow for calcula- 
tion of the complexity of the program the equation becomes: 


(se ; 
ee ney x vy x | SEs ta) + 2D ITE og, 


This formula, when used to determine the complexity 
of a pregram in relation to a programmer's debugging perfor- 
Mance, accounted for over twice as much variance in perfor- 
Mance as a metric that counted solely the total number of 
program statements [{ Ref. 41}. The resultant value, when 
applied to programs on board, will provide an estimate of 
the complexity of a prograa, thereby refining the estimate 
of the quantity of resources required to make alterations to 
the software. 

Implicity treated in the above formula is the way in 
which modularity affects the complexity of the program. The 
use of modules such as functions, subroutines and macros 
will reduce the program volume through their inclusion. 
They are performed multiple times during execution of the 
program, but will be present only a single time when the 
software 1S reviewed or checked. Through their single 
inclusion, they reduce the total number of operators and 
Operands present, directly reducing the program volume and 
increasing its comprehensibility. Additionally, as Halstead 
indicated, the number of unique operators will increase with 


the addition of subroutine or function calls, again reducing 
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the overall complexity of the systen. Interesting to note 
at this point is that Halstead, through further development, 
has stated that E will vary with the square of the volume 
and not linearly in relation to the program's potential 
Minimum volume (the best implementation possible) [Ref. 42]. 
This also demonstrates that as modules are added the 
system's complexity is reduced, not linearly, but as some 
function of the square. 





2. Estimation of Adaptive Maintenance Workload 








The estimates of the amount of personnel effort 
needed will require the combination of the above complexity 
metric and the benefit of previous experienc on similiar 
projects. The metric can, to a large extent, predict the 
amount of time required to understand a program, a factor 
that is critical to the proper conduct of adaptive mainte- 
nance. This effort should be required each time the systen 
is to be enhanced. The shortcoming of the model is the 
requirement for a prediction of the frequency of enhance- 
ments and their degree. The degree of alteration is a defi- 
nite consideration as it will govern the time and effort 
required to accomplish the changes. Major alterations will 
take greater time and effort than will minor ones, but a 
large number of minor changes can easily outweigh one major 
change in effort. 

The only present method used to estimate the 
frequency of alteraticns required is experience. The degree 
of enhancement should be divided, at least initially, into 
major and minor. A major enhancement would consist of at 
least the replacement of an old module of the system or the 
addition of a new one. A minor enhancement would consist of 
an alteration to a module in which either a line of code is 


rewritten or replaced, or the module itself is rewritten 
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with its function remaining as it was prior to the mnodifica- 
?H#o/n. Until further data is accumulated on the type of 
enhancements conducted, this initial distinction should be 
used to improve the estimation process. 

Two methods are suggested for the use of the 
complexity metric. The first would consist of simply multi- 
plying the average time of all enhancements by the ratio of 
the complexities for the new system to the average complexi- 
ties of all the previous systems. The preferred method, 
though, is to use the average time +o conduct the enhance- 
ment and the average complexity thereof broken out by the 
enhancement degree. Fach resulting average by enhancement 
degree should then be multiplied by the ratio of the new 
system's complexity to the average of the previous system's 
complexity and the frequency of enhancements per project. 
This formula is: 


~x (maj) x N (maj) X(min) x N (min) “| 
AM = Se a Se <7> 
_E(aver. for maj) E(aver. for min)_ 


where, 


AM= total adaptive maintenance required in man-hours, 


x(maj) = the average time to add a major enhancement, 

x(min) = the average time to complete a minor enhance- 
ment, 

E(aver for maj) =the average complexity of major 


enhancements using equation <6>, 
E(aver for min) = the average complexity of minor 
enhancements using equation <6>, 
N(maj) = the average number of major enhancements, 
N(min) = the average number of minor enhancements, and 


E = the complexity of the program using equation <6>. 
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N(maj) and N(min) can be used in the equation in two ways. 
The first, as presented, is as the frequency that enhance- 
ments of the two degrees have occurred in the past. The 
other way could be to use an estimated number of enhance- 
ments, if management has some idea of special circumstances 
in which these numbers will vary from past events. 


D. MCDEL AGGREGATION 


The entire maintenance effort required for the project 
from time the system is accepted at the maintenance facility 
can be calculated by adding the estimated corrective mainte- 
nance workload to the adaptive maintenance workload. This 


yields: 
TH = A + CM <8> 


where, 


TM= total combined maintenance required in man-hours. 


This result should yield an estimate of the total mainte- 
Nance effort required and needs to be subdivided into years 
to be more useful to management. One method of accon- 
plishing this is to divide the total maintenance effort by 
the estimated number of years remaining in the project. 
This will yield a straight line average of maintenance that 
fails to show any variations that normally present then- 
selves later. Its advantage is that it is extremely simple. 
Another method is to reevaluate the project yearly using the 
above formulas and actual experience. This may prove infeas- 
ible as the estimation needs to be conducted well in advance 
of that year for budgeting purposes. 

The last method for developing annual personnel require- 
ments is to return to the components of maintenance. Worse 


case corrective maintenance can be estimated as remaining at 
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least ccnstant if not decreasing throughout the remaining 
life of the software. The error rate will prove highly 
dependent on the enhancement rate. It seems reasonable to 
assume that, if a large number of enhancements are made, the 
system's error rate will increase correspondingly. Thus, 
the normal assumption that the error rate decreases as the 
project continues will not prove valid, if a sizeable number 
of enhancements are made. Additionally, if no enhancements 
are made the error detection rate will never disappear 
entirely and will remain much higher than expected. This 
variation should be insulated against by utilizing an annual 
detection rate where the initial number of estimated bugs is 
divided by the estimated annual detection rate. The esti- 
mated annual detection rate can be estimated from the bug 
detecticn rate established during the bebugging test. 
Periodic retesting of the system should be conducted espe- 
Cially when a major enhancement has been added to revalidate 
the error detection rate. 

The adaptive maintenance phase, at over seventy percent 
of maintenance costs, accounts for the largest portion of 
the software maintenance budget in government activites 
(Ref. 43]. Therefore, it is this area that demands the 
greatest efforts to account for cyclic activity. Again, no 
predictive ability for the number of enhancements by type 
exists in this model and the only method is to use data 
obtained from previous projects to determine the enhancement 
rate at different stages in the maintenance phase. These 
estimates, broken out by year, could then be added to the 
anticipated corrective maintenance loading to obtain the 
amnual figures to be used for planning. This model does 
develop a prediction of the quantity of resources required 
to implement each enhancement by type. 
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E. CHAPTER SUMMARY 


The model has been developed considering the two 
elements of maintenance as defined here, corrective and 
adaptive maintenance. It has further been shown to yield an 
estimation of the total manpower requirements for the 
project from the time of assumption of maintenance responsi- 
bilities. These figures have been manipulated to provide 
annual estimates of manpower requirements. Halstead's 
effort metric and Gilb's bebugging provide the basis from 
which the model was developed. 

The largest requirement for this model, or any model for 
that matter, is to obtain data with which the results of the 
model can be calibrated and tested. The requirement exists 
for the establishment of a data base on personnel expendi- 
tures during the maintenance cycle. Without this data any 
model developed cannot be tested fully. Additionally, the 
models developed will not be calibrated properly to allow 
for their fullest utility. 

The model developed here has been designed to maintain, 


to some extent, SMmiplscityein orders to allow it to be 
employed in a working environment. Tt has been outlined so 
that the reasoning should be evident, allowing managerial 


personnel the capability to adjust it to fit their situa- 
tion. The model is based on those concepts that have appa- 
rently received favorable reviews and have been employed in 


other Similiar situations. 
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IV. CONCLUSIONS 


As this research has shown, it is important to 2stablish 


early in the life of a software project the desire to reduce 


Maintenance costs. With this commitment, the development 
phase may take longer and cost more, but the long-tern 
results will be worth the extra effort. Maintenance costs 


will continue to consume the largest portion of the 
resources allocated to software systems and only through the 
conscientious application of the tenets outlined in Chapter 
II can this portion be expected to be reduced. 

Most important of these tenets is the use of structured 
design and structured programming to aid in the reduction 
and identification of potential errors early in «he life of 
+he project. This is the time when they are least expensive 
to repair. Reused code will provide benefits throughout the 
@mtire life of the project by reducing devlopment and 
maintenance costs by providing previously coded and tested 


modules for inclusion in the software being developed. The 


use of a high level language will increase the 
maintainabilty on the program by making ae nore 
understandable. 


The estimation of the personnel requiréments will aid 
Management during the budgeting process. The number of 
unplanned occurrences, such as exceeding budget limitations 
or unexpected levels of maintenance, will decrease because 
of greater comprehension of the maintenance phase and its 
components. 

This model is a first attempt at developing a systen 
that ele estimate the personnel requirements Lon 


maintenance. It has been presented in such a manner as to 
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increase understanding of the items that affect maintenance 
in both favorable and unfavorable ways. The reader is 
encouraged to utilize the model and adapt it to his own use 
by applying it to his own Situation and requirements. 

An important item to note is that a data base has to be 
established that catalogs those items concerning the 
software that are important to the estimation and 
understanding of the software maintenance process. This 
information should include at least error detection rates, 
correction times, number of enhancements made as well as the 
estimated rates for each of these items. 
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